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0O (54) Title: SYSTEMS AND METHODS FOR DIMENSIONING A WIRELESS COMMUNICATION SYSTEM 

25 (57) Abstract: A method of dimensioning a wireless communication system configured to support a plurality of applications. The 
method includes, for each application, estimating a percentage of subscribers of the wireless communication system that will use 
Q the application. Then a subscriber profile is determined for the application based at least in part on the estimated percentage of 
subscribers that will use the application. Then a busy hour traffic per subscriber ratio is determined for the application based at least 
in part on the subscriber profile for the application. 
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SYSTEMS AND METHODS FOR DIMENSIONING A WIRELESS 
COMMUNICATION SYSTEM 

CROSS REFERENCE TO RELATED APPLICATIONS 
5 [001] This application claims the benefit of priority under 35 U.S.C. § 1 19 to U.S. 

Provisional Application Serial No. 60/236,927, filed September 28, 2000, which is fully 
incorporated herein by reference, 

BACKGROUND OF THE INVENTION 
10 1. Field of the Invention 

[002] The invention relates generally to wireless communications, and more 

particularly to a systems and methods for dimensioning a wireless communication system, 
2. Background 

[003] In wireless communication systems, radio system engineers must be able to 

15 determine the number of base stations required to support a given number of users in a 
given area. This process, for purposes of this specification and the claims that follow, is 
referred to as dimensioning the wireless communication system. In a pure circuit switched 
system, this is not a problem; however, when packet data is incorporated, it becomes 
dif0cult to determine the number of base stations required. This is because packet data 

20 capability allows a complex mix of subscriber applications such as web access, e-mail, and 
multimedia applications. These applications greatly increase the number of variables that 
Effect capacity in wireless communication systems. For example, new variables include 
burstiness of packets, packet size, delay constraints, and delay variations. Unfortunately, 
the traditional packet data statistics used to track these variables do not correlate with the 

25 statistics used to track variables that effect circuit-switched applications. 

[004] In particular, the Erlang model traditionally used to measure capacity for 

voice-centric systems is not applicable to packet data applications. Simplistically, the 
Erlang model uses the average number of incoming calls per second, the average length of 
a call in seconds, and the number of lines available to take the calls. If these three 

30 variables are known, Eriang^s formula can be applied to determine the percentage of 
incoming calls for which no line will be available, i.e,, the percentage of calls that will be 
blocked or delayed. 
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[005] 



Erlang's equation has the form: 



(1) 



where t - the numb er of incoming calls; 
and c = the number of lines. 



[006] The traffic (t) is often expressed in the dimensionless unit "Erlang." Traffic 

in Erlang is a number that signifies the expected number of lines, or circuits, that would be 
occupied if there were no blocking. It is found by multiplying the total expected number 

10 of calls per time unit, i.e., average incoming calls per second, with the average length per 
call. The left hand side of equation (1) provides the proportion of calls that are blocked. 
Therefore, if (t) and (c) were known, the number of blocked calls can be determined. 
[007] In actuality, modem systems require a much more complex model than 

provided by equation (1), but the basic principle is still the same* therefore, radio systems 

15 engineers look at the traffic (t), number of circuit (c) available, and the number of blocked 
calls deemed acceptable, when planning how many base stations are required and where to 
position them.. Because of the complexity of the systems, the traffic (ty is determined 
based on complex traffic models that account for issues such as the radio resource 
management scheme and the effect of user mobility on the traffic volume per call. The 

20 number of blocked calls is referred to as the grade-of-service (GOS). By specifying the 
GOS and determining the traffic (t) in accordance with the appropriate traffic model, the 
radio systems engineer can detennine the number of circuits (c) required. GOS is 
typically applied to the busy hour, which is a sliding 60-minute period during which the 
maximum total traffic load in a given 24-hour period occurs. Packet data applications, 

25 however, do not use GOS. Instead, packet data applications are characterized by quality- 
of-service (QOS), which is measured by bit-error-ratio (BER). Thus, packet data 
applications look at the number of bit errors as opposed to the number of blocked calls. 
Traditional models do not provide a method for equating GOS requirements in circuit 
switched applications with QOS requirements in packet data applications. 



- 3 - 



WO 02/28118 



PCT/EP01/11203 



3 

S UMMAR Y OF THE INVENTION 
[008] In accordance with an aspect of the invention* systems and methods for 

dimensioning a wireless communication system that supports both circuit switched and 
packet data applications are provided as a way to equate GOS and QOS requirements, 
5 One feature of this aspect is that engineers may better determine an optimal number of 
base stations required to support a given number of users in a given service area of the 
wireless communication system. 

[009] In one embodiment, a method of dimensioning a wireless communication 

system configured to support a plurality of applicationsis provided, in which, for each 

10 application, a percentage of subscribers of the wireless communication system that will 
use the application is estimated, A subscriber profile for the application is then 
determined based at least in part on the estimated percentage of subscribers that will use 
the application. A busy hour traffic per subscriber ratio is then determined for the 
application based at least in part on the subscriber profile for the application, 

15 [010] The method may further comprise determining a total busy hour traffic per 

subscriber ratio for the wireless communication system from the busy hour traffic per 
subscriber ratios for each application. A total traffic capacity is then estimated for the 
wireless communication system. The number of subscribers the wireless communication 
system will support is then calculated by dividing the estimated total traffic capacity by 

20 the total busy hour traffic per subscriber ratio* 

[011] Other aspects, advantages and novel features of the invention will become 

■ Apparent from the following Installed Description of Preferred Embodiments, when 
considered in conjunction with the accompanying drawings. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

[012] Preferred embodiments of the present inventions taught herein are 

illustrated by way of example, and not by way of limitation, in the figures of the 
accompanying drawings, in which: 

[013] FIG. 1 is a block diagram that illustrates an exemplary wireless 

30 communication system* 

[014] FIG* 2 is a flow chart that illustrates a method for determining the capacity 

of a wireless communication system, such as the system illustrated in FIG- 1. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[015] The architecture of a wireless communication system 100 is illustrated in 

figure 1, In a wireless telecommunications system, a coverage area is divided into a 
plurality of cells. System 100 is divided into three interconnected components or 
5 subsystems: A plurality of mobile devices, an example of which is designated as mobile 
device 102, a Base Station Subsystem (BSS) 104, and a Mobile Switching Center (MSG) 
118. Generally, the mobile device 102 is the mobile equipment carried by a subscriber to 
system 100, Traditionally, mobile devices used in wireless communication systems 100 
have been voice centric devices, such as cellular phones. More recently, however, data 

10 centric devices such as laptops and PDAs are commonly designed for mobile applications. 
Moreover, even today*s cellular phones are typically configured for data applications. 
[016] BSS 104 is comprised of multiple base transceiver stations (BTS), an 

example of which is designated BTS 108, and a base station controller (BSC) 110. The 
BTS 108 is usually in the center of a cell and consists of one or more transmitters with 

15 antenna. A cell is the coverage area of a particular BTS 108. Low power transmitters are 
utilized so that frequencies used in one cell can be used in cells that are sufficiently distant 
to avoid interference. BTS 108 establishes radio links and handles radio communications 
over an air interface 112 with mobile devices 102. Each BSC 110 manages a plurality of 
BTSs 108. This involves allocating and managing radio "channels" and controlling 

20 "handoffs" of communications involving mobile devices 102 from one BTS 108 to 
another. BTS 108 and BSC 110 communicate over a standardized "Abis" interface 114, 

■S*A ;« fm-« "EkOr* 1 in ^ntnmnni^dtpo «nfh AARP 1 1S rivpr i» et^nHflivl i-Twl interface 116. For 

example, interface 116 can use a standardized base station application part (BSAP) 
protocol or a standardized SS7 protocol. MSC 118 manages communications between 

25 mobile devices 102 and between mobile devices 102' and public networks. Examples of 
public networks that MSC 118 can interface to include the Integrated Services Digital 
Network (ISDN) 120 and the Public Switched Telephone Network (PSTN) 122. 
[017] System 100 can often support a variety of data services. For example, 

MSC 118 can interface mobile devices 102 to the Internet through an ISP 132. MSC 118 

30 can be interfaced to an ISP 130 through PSTN 120 or ISDN 122, but the Internet uses 
packet data communication, which is non-real time communication. Because non-real 
time communication is unacceptable for voice communications, system 100 uses a circuit 



- 5 - 



\VO 02/28118 PCT/EP01/1 1203 

5 

switched carrier 134 to carry communications to and from the mobile devices 102. 
Therefore, a Packet-Assembler-Disassembler (PAD) (not shown) is also included when 
interfacing MSC 118 to the Internet. The PAD converts circuit switched communications 
from mobile devices 102 to packet data communications and vis versa. 
5 [018] As mobile data applications have proliferated, however, a need for faster 

data service for mobile devices 102 has developed. Like the Internet, mobile data services 
can use non-real time communication* Therefore, wireless communication systems, like 
system 100, typically include packet data carriers 136 for communicating packet data 
between mobile devices 102 and the Internet. Typically, mobile packet data is not 

10 controlled by MSC 118, Instead, Packet Data Service Network (PDSN) 138 handles 
communications between mobiles 102 and the Internet over packet data carriers I3"6. 
PDSN 138 includes packet data core network 140. Authorization, Authentication, and 
Account node (AAA) 142, and the home agent 144, Packet data core network 140 handles 
the routing of traffic between mobile device 102 and the Internet. Home agent 144 is a 

15 router on a mobile device's home network which sends packets to the mobile device while 
it is away from its home network. It also keeps current location information for registered 
mobile devices called a mobility binding. AAA 142 is a server that stores information 
related to services and authentication for mobiles 102. The AAA server can also supply 
security parameters. 

20 [019] Different data services, whether circuit switched or packet switched, will 

require different GOS or QOS, respectively. The Internet today provides a service that has 

i-r»n^H "Uf»ci f»ffni-f " Whm rmR sftnHft a r*ar1ret_ fhe netwnrk forwards it as best it can 

UVVH VfcMXWU UWUIr V1AV» »t • * UUW wvmim-w i— J " "7 ' " ' " 

given the other traffic offered at the moment, but makes no specific guarantee as to the 
rate of delivery or that the packet will be delivered at all. Many computer applications 

25 operate very naturally in a context that does not guarantee bandwidth, and best-effort 
service has been demonstrated to be effective for the. Best-effort service divides up the 
available bandwidth among current users. Having an application sometimes run a bit 
more slowly does not usually cause serious user dissatisfaction. For applications such as 
remote file access, in fact, best-effort service has proved very effective. Of course, best- 

30 effort service is tolerable only within limits, and a network that is totally congested will 
not be acceptable. 



WO 02/28118 



PCT/EP01/S1203 



6 

[020] An alternative to best-effort service is one that requires the traffic source to 

declare its service requirements, so that the network can either reserve and guarantee this 
service or explicitly refuse the request When there is excess bandwidth, both best-effort 
and reserved bandwidth service work well to make users happy. But when there is 
5 congestion, the choice is between slowing all users down somewhat, as is the case with 
best-effort service, or refusing some users outright in order to folly serve others with 
reserved bandwidth. For some applications, such as real-time audio and video, a reserved 
service may be preferable. As a result, system 100 can offer a variety of data applications 
over a variety of bearer services. This sort of variation in the bearer service is described 

10 by the QOS, which is understood in the technical community as covering control of delay, 
bandwidth, degree of guarantee versus degree of sharing, loss rates, and so on. 
[021 ] The Internet and mobile data packet applications are moving from single, 

best-effort service to a more complex model with explicit options for QOS, to support new 
applications such as video and audio. On the circuit switched side, different bearers are 

15 specified in terms of GOS* For example, one traffic model for a CDMA2000 wireless 
communication system uses two bearer services options for circuit switched voice 
applications* The first service option, rate set 1, operates from 9.6Kbps to 1.2Kbps. The 
second service option, Rate set 2, operates from 14,4Kbps to L 2Kbps. The CDMA2000 
standard allows for Circuit Data Service options at Rate Set 1 (9.6kbps), Rate Set 2 

20 (14.4kbps), and a new service option at 64kbps. To use the new service option effectively, 
ISDN service is required end-to-end. For packet data applications, CDMA2000 Phase 1 
will provide for a maximum Packet Switched service rate of 144kbps. 
f0221 Frnm a subscriber fend-usert and source annlication nersnective, four major 

L~~~ J " \ " ' * A 

classes have been identified which better characterize packet switched data traffic patterns: 
25 interactive, background, conversational, and streaming. In order to maintain a QoS that 
meats the interactive class requirement, the end-user requirement is ttiat the request- 
response sequence be preserved as well as payload content. The interactive class can also 
be classified as non-real-time. A good example would be traditional Web applications or 
email. In the background class, the only end-user QoS requirement is that the payload 
30 content be preserved. No expectations are placed on the delay or the variation of delay. 
The background class can also be classified as non-real-time. Background services can 
include data that is pushed or pulled to or from the terminal when the user is attached to 
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the network, but not necessarily active. Examples are Stock Market information, Sport 
News, email, Fax, etc. Other examples could be DNS traffic* other mobile information 
services that are both commercial and society related, and software download of terminal 
properties. These services should be low cost and make use of spare bandwidth. Traffic 
5 in the interactive class has higher priority in scheduling than background class traffic, so 
background applications use transmission resources only when interactive applications do 
not need them. Note that some of the mail traffic defined in the interactive class could 
also be considered part of the background class. Interactive class and background class 
are mainly intended for traditional Internet applications like Web applications, email, 
10 Telnet, FTP, and News. In both classes the resources are reserved dynamically and the 
responsiveness of the interactive applications is ensured by the separation of interactive 
and backgrounds applications. 

[023] In the conversational class, the fundamental OoS characteristic is to 

preserve the time relation (variation) between the source information and final destination 

15 of the information stream with low bi-directional time delay. This class is the most time 
delay sensitive and therefore time delay must be maintained even at the expense of 
payload content if necessary. Conversational class can also be classified as real-time. The 
intended application for this class is speech. In the streaming class, the fundamental QoS 
characteristic is to preserve time relation between the source information and final 

20 destination of the information stream. Because the streaming class traffic is not so delay 
sensitive (however, it is sensitive to delay variation) as that of conversational class, it may 
- fallow for a better error rate than conversational class. The streaming class can also be 
classified as real-time. A good example of this class would be video/audio streaming from 
a Web site. Conversational and streaming classes are intended to carry real-time traffic 

25 flows like speech and video streaming. Whereas, the interactive and background classes 
are characteristic of traditional Internet applications like Web applications and email, and 
for a number of vertical applications like Telemetry and Point of Sale. The following 
characteristics are of interest for real time applications: 1) Duration of one session 
(ie.'calF), 2) Byte volume up and down per session, 3)Packet size up and down, 4) 

30 Number of sessions (i.e. balls') per day, and 5) Distribution of sessions (i.e. 'calls') 
during the day. 
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[024] A major challenge in dimensioning a wireless communication system that 

embodies packet data and circuit switched applications is that of determining the sector 
capacity in a complex mix of subscriber applications such as voice, web access, email, 
multimedia, etc. In such systems, the number of variables that affect sector capacity such 
5 as burstiness of packets, packet size, delay constraints, delay variations, etc., is very high. 
A Dimension Tool that uses a multi-step process, using look up tables, spreadsheets, and 
propagation models can be used to overcome these issues. The methods used by such a 
tool will now be discussed. In developing the tool, engineering simplification are made 
with regard to call model variables and their impact on the throughput of data* The 
10 traditional approach of expressing capacity, as an Erlang number, is not quite applicable 
here due to packet switched applications, hence the traffic is expressed in terms of bits 
carried in the busy hour (in forward and reverse links),and the capacity is expressed in 
terms of bits per second, 

[025] Figure 2 is a flow chart that illustrates the multi-step process used by the 

15 tooL Table 1, at the end of this description, illustrates some sample results from applying 
the multi-step process to a hypothetical system. And column A of table 1 lists the 
available bearer services and applications. In step 202, the subscriber penetration for each 
application must, be determined and^ using the penetrations, the percentage of total 
subscribers using a particular application at any given time is found. In order to make this 
20 determination, the percent of the total subscribers that subscribe to a bearer service 
associated with a given application is multiplied by the percent of subscribers that actually 
tise the application. The product is then multiplied by a usage scaling factor that is 
i^tfinded to annroximate what nercent of the time a tvoical subscriber will actually use the 

— --— ■ — ~T X - " C -- - - - * 

application. This calculation can be illustrated using the first application in table 1 , which 
25 is a Web application, with images, over a packet data bearer service. Column B shows 
what percent of subscribers subscribe to the applicable bearer service, in this case the 
packet data bearer service. Column C shows the percentage of subscribers that subscribe 
to the Web application. And column F shows what percent of the time these subscribers 
are actually using the service. Thus, step 202 consist of multiplying the values stored in 
30 columns B, C, and F, and storing the result in column H. The result of the calculation for 
the Web application being considered is: .80 x .20 x .50 = .08 or 8%. 
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[026] Next, in step 204, an average subscriber profile is determined. This 

determination involves estimating the number of application sessions per day engaged in 
by a typical subscriber for each application (column D) and multiplying the estimate by 
the average time for each session in seconds (column E)> This product is then divided by 
5 3600, the number of seconds in an hour, to generate a busy hour factor (column G). 
Continuing the analysis for the web application used to illustrate step 202, the result of this 
calculation is: (3 x 250)/3600 .20 or 20%. The busy hour factor is then multiplied by the 
percent of subscribers using a particular application at any given time, i.e., the value in 
column H, and the number of sessions for each of these users, i.e., the value stored in 
10 column D, with the result being stored in column I. The result of this calculation is: .20 x 
.08 x 3 - .048. 

[027] In other words, the result stored in column I represents the busy hour 

calls/sessions per subscriber averaged over the total subscribers in the wireless 
communication system. Since this calculation is performed for each application, i.e., for 

15 each application listed in column A of table 1, this calculation provides the average usage 
behavior of a subscriber for each application, or the average subscriber profile in the busy 
hour. The profiles can then be used to calculate the total busy hour data bit requirement 
for each subscriber, which is denoted the "Raw Data Bits/' The Raw Data Bits is the 
common measurement criteria for both packet data and circuit switched applications. 

20 Once the Raw Data Bits are determined for each application, they can be added in a purely 
arithmetic fashion to clearly describe the traffic per user across all applications in the 
System. The process and importance of finding and using the Raw Data Bits for each 

will be clearlv illustrated in the discussion below. 
[028] In step 206, the average busy hour traffic in kilobytes per busy hour per 

25 user (KB/BH/user) are calculated. First, however, the total kilobytes per application is 
found by multiplying the number of packet calls per session (column J) by the number of 
datagrams per call (columns K and L) and the number of bytes per datagram (columns M 
and N), This is earned out for both the forward and reverse link. Second, the total 
kilobytes per application is multiplied by the average subscriber profile form step 204, 

30 with the results being stored in columns O and P. It should be noted that for circuit 
switched applications, the number of data grams per call and the number of bytes per data 
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gram do not apply; therefore, these columns are blank for circuit switched applications in 
table 1 . For the current example, the average busy hour traffic per subscriber is: 

(10 x 60 x 650) x -048 - 1 8.72 KB/BH/user (forward link); 

5 

(10 x 30 x 65) x .048 = .936 KB/BH/user (reverse link). 

[029] It should be noted that the actual values that appear in table 1 may be 

slightly different than the values calculated here, because of differences in rounding the 
10 various results and sub-results. Additionally, the calculation performed in step 206 can 
also account for various overhead bits. For example, if the wireless communication 
system is a CDivIA2000™ system, then step 206 can account for overhead bits included in 
the CDMA2000™ model. 

[030] Because table 1 contains data for a CDMA2000™ system, the actual values 

15 contained in columns Q and P are different than the above calculation would predict. 
Fundamentally, however, the values for columns O and P are arrived at via the above 
calculation. 

[031] Certain embodiments of system 100 do not implement a multi-user 

scheduler supporting traffic classes with different QoS requirements. Instead, these 
20 embodiments use a single user scheduler based on the best effort-principle, where a delay 
constraint of 5 seconds is typically considered a reasonable bound. Therefore, current 
embodiments consider all packet data application as an interactive class of traffic and 
circuit switched applications as conversational class. Interactive class is mainly used by 
applications like web browsing and has following service session characteristics: 

25 

(1) Duration of one session; 

(2) Number of requests in a session; 

(3) Byte volume up and down per session: 

(4) Packet size up and down; 
30 (5) File size down; 

(6) Inter request times; 

(7) Number of sessions per day; 
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(8) User access (rate, QoS) (e.g. best effort with max rate); and 

(9) Distribution of sessions during the day* 

[032] The values stored in columns D, G, J, K, L, M 3 and N of table 1 describe 

5 such behavior. Thus almost all the data up to now is input data that currently has UMPS 
default values. Columns O and P start the analysis of determining busy hour traffic per 
subscriber. This is done for each application and column O and P store the Kbytes per 
subscriber in the busy hour for forward and reverse link. The sum total of this traffic is 
actually the payload that is transacted during the busy hour for each application, It is an 
10 average per subscriber considering the whole population in the system. The subsequent 
analysis attaches various overheads on this payload and attempts to figure out the Raw 
Data Bits on the air link in both directions. 

[033] One such overhead is the scheduler efficiency factor, which is found for 

both packet data and circuit switched applications in step 208. For packet data 

15 applications, the scheduler efficiency at different data rates is a factor of burstyness of the 
data, i.e., its duty cycle, and such characteristics as packet size. Simulations for the 
forward link throughput in an ISO-2000-A (CDMA2000) system are provided in Vieri 
Vanghi, IS-2000A Forward Link Throughput (Vanghi), EWU/TT/R-Q0:002, which is 
incorporated herein by reference in its entirety, and which is used to provide some of the 

20 details for the following scheduler efficiency calculations. The scheduler efficiency is 
stored in columns S and T, for the forward and reverse links respectively. Using the 

.^c£i xr«,-« /^»>vi„*««« o T\ ™*>A +Ua +™*V^r> pnlnrrirto C\ orirl P fnr p-ar/h nser_ the 

CXiUJlCllWiy ligULG ^trUl LUlJJLlk> LD OXLKX J. J OllU LJ.1W UOlilV ilk vvimiuu w uuu a 7 

Raw Data Bits corresponding to 100% scheduler efficiency are determined for each 
application. Keep in mind that 100% scheduler efficiency is an ideal number which is 
25 possible only in cases where there are no constraints in the system such as delay 
constraint, delay variation, etc. 

[034] Table 2 illustrates an example calculation of a scheduler efficiency for a 

packet data application. The scheduler efficiency in table 2 is associated with activity 
factor or the duty cycle of the packet call models. It is assume that the efficiency factor is 
30 linearly related to the activity factor. It is further assumed that in general this approach 
applies to any call model, and the assumed delay constraint of 5 seconds is considered the 
minimum performance bound in a best effort implementation. Therefore, if the activity 
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factor for at least two data rates is known, then a linear equation can be developed to find 
the scheduler efficiency factor for any data rate. 



Data Rate 


Activity factar 


Scheduler Efficiency 


38.4 kbps 


A1 =0.089 


N1 = 0.68 


y.6 kbps 


A2 = 0.385 


N2 = 0.74 



Table 2 



[035] The table 2 scheduler efficiency call model is taken from Vanghi so that the 

average packet size is 4,1 Kbytes, the packet inter-arrival time is 10 sec, and the session 
duration is 10 packets, with a maximum delay of 5 seconds. Because a linear relation 
10 between the scheduler efficiency and the channel activity factor for a user is assumed, a 
linear equation can be applied to the data points above to find the slope and the intercept 
for the relationship* The following equation is used to find the slope: 

Slope M - (N2 - N1)/(A2-A1): 
15 = (0,74-0.68)/(0.385-0,089); 

-0.2027. 

[036] To find the intercept we apply (N-NI) = M x (A-Al), where we substitute 

A = 0; Thus, intercept C = N = 0.68 - 0.2027 (0.089) = 0,662, and the scheduler efficiency 
20 N at an activity factor A is now given by: 

N = MxA + C; or 

N - 0,2027 xAt 0.662. (2) 

25 [037] This formula is a simplification and is justified by the following logic: If 

the user peak data rate is constant and the activity factor is reduced, the scheduler has to 

^ - 'ill 1 t ! JaU 

accommodate more users in the system in order to iully exploit tne avanaoie oanuwiuui. 
More users instinctively implies that the scheduler efficiency goes down and under the 
model illustrated by equation (2), as the channel activity factor goes down the scheduler 
30 efficiency does indeed go down. Similar logic applies to the opposite case of a higher 
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channel activity factor. If the user peak data rate is increased and a constant activity factor 
is maintained, then the number of users in the system will have to be reduced in order to 
accommodate the increased average data rate per user. So while the increased data rate 
could have signaled a reduction in scheduler efficiency, the lesser number of users would 
5 imply the reverse, and overall the scheduler efficiency will stay the same. In this case, the 
channel activity factor will decide the scheduler efficiency. Under these conditions both 
of these values stay the same. On the other hand, if the user data rate increase is 
accompanied by a proportionate decrease in the activity factor then the scheduler 
efficiency goes down as well, which is also indicated by the model illustrated in equation 
10 (2). 

[038] Therefore, Equation (2) is used to calculate the scheduler efficiency for any 

call model in table 1. Continuing with the above example, the scheduler efficiency factor 
for the Web application can be determined using the equation N = 0.2027 x A 4- 0.662, 
where A is replaced by the value stored in column O or P divided by the data rate from 
15 column Q or R, respectively, depending on whether the calculation is for the forward or 
reverse channel. For the Web application then, the calculation is: 

0.2027 x (19.2/38.4) + 0.662 - .76335 (forward link) 

20 0.2027 x (1 .416/38.4) + 0.662 = .66948 (reverse link) 

-Brv^QI Tn cif*r\ 90R rimnit switched nnnlirifltinns are treated sliehtlv different. The 

goal is to characterize the circuit switched application so as to arrive at the same Raw Data 
Bits figure as computed for packet data applications. This will allow the two to be merged 

25 to find the total circuit switched and packet switched traffic bits. Voice and other circuit 
switched applications like fax are real time; therefore, they have stringent delay constraints 
as well as stringent delay variation constraints. Hence, it is clear that they should have 
relatively lower efficiency factors. The traditional concept of Grade of Service (or 
blocking probability) is now translated into an in-efficiency factor that is equivalent to the 

30 scheduler efficiency factor in packet switched applications. Considering an Erlang B 
model and a 2% GOS, 36 trunks give an Erlang capacity of only 28 Erlangs. This 
effectively means an efficiency factor of approximately 28/36 = 78%* 
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[040] Note that this is a new traffic engineering approach and has been created to 

merge the packet data and circuit switched applications into one measurement The 
Erlang B model efficiency factor is equated to a scheduler efficiency factor in voice 
application. Since the Eb/Io requirement, which is a metric used to indicate the signal-to- 
5 noise ratio for a particular signal for voice is greater than that for packet data by about 1 3 
dB, the scheduler efficiency calculation includes another efficiency factor for circuit 
switched applications corresponding to 10 A (-1.3/10) = 74%. These two factors result in an 
average utilization efficiency of 58%, Therefore, the value stored in columns S and T for 
circuit switched applications is 0.58* In order to calculate the Erlang efficiency of voice 
10 calls, the whole air link capacity available for a voice call from the perspective of call 
admission control is considered. This means that voice calls get a priority over data calls 
in call admission. 

[041] ' The process to this point has primarily considered only the pay-load on the 

air interface, but the framing overhead at the air interface and the physical layer are also 

15 considered in step 210. For the sake of simplicity, and backward compatibility, these 
values for circuit switched voice have been lumped into the voice activity factor. For data 
applications, these value are calculated for different data rates. Columns U and V 
incorporate this framing overhead at the physical layer in the forward and the reverse 
links. It is interesting to note that the framing overhead goes down as the data rate goes 

20 up. This is due to the fact that more bits are packed into the same 20 msec frame for 
higher data rates, while the CRC and the tail bits remain constant. Similar overheads 

- , J„« + A \/f A r* lo^^r rvi/f»rk^«ii^ i« r>T T>fK/Tf TV DHT T/T TT T fV-j-m^c ac nc thfi TCT.P 

retransmission overhead. MAC layer overheads are shown in columns W and X* The 
RLP retransmission overheads are shown in the columns Y & Z. 

25 [042] In step 212, the normalized busy hour traffic per subscriber (normalized 

traffic) is determined. The normalized traffic, therefore, is the Raw Data Bits. Columns 
AA and AB store the normalized traffic considering the impact of the overheads form the 
previous step. The Raw Data Bits for various circuit switched and packet data 
applications are normalized so that now they are identical in terms of air interface 

30 capacity. Thus, they can be summed in algebraic fashion. In step 214, the total busy hour 
traffic per subscriber (total Raw Data Bits) is calculated as a simple addition of the values 
stored in columns AA and AB for each application. Next, in step 216, the total sector 
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capacity in terms of the number of subscribers per sector is determined by dividing traffic 
per subscriber by the total sector capacity. 

[043] Table 3 summarizes the sector capacity for voice throughput, effective 

throughput for packet data users, and packet data raw throughput, respectively. Table 3 is 
5 based on information derived from Vanghi > e.g., the values are determined for a 60° 
antenna, NoW = -105 dBm, Voice Eb/lo = 6 dB, and packet data Eb/lo = 4.7 ciB. 
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Table 3 



[044] For voice throughput, the efficiency factor is very low because of two 

5 factors already mentioned: First, circuit switched voice has an Erlang B factor for a GOS 
of 2% that results in Inefficiency; and Second, the higher Bb/To requirement compared to 
data has another correction of 1.3 dB or 65%. The throughputs in table 3 are used to 
calculate the sector capacity in step 216. The sector capacity for urban and suburban 
environments are calculated separately. Thus* given the sector capacity in Kbps and the 
10 Raw Data Bits per user in the busy hour, sector capacity is calculated in terms of the 
number of users supported per sector per frequency assignment. 

[045] This is a simple approach, but helps tremendously in understanding and 

evaluating the paradigm change from circuit switched to packet switched applications. 
Current embodiments do not implement subscriber traffic classes per QoS required, e.g., 

15 interactive, background, conversational and streaming, and instead use a single scheduler 
operating on the best effort principle, with a delay constraint of 5 seconds. But a provision 
is made for future changes in traffic classes with guaranteed QoS that will result in 
increased efficiency when multiple classes of traffic are introduced. Several of the values 
used in table 1 and in the underlying assumptions for the model are derived from George 

20 Bertini, Subscriber Traffic Model for CDMA2000 lxRTT, EWU/UT 1551-3/FCP101 
0746, which is incorporated herein by reference in its entirety. 

[046] The model embodied in table 1 is easily turned into a spreadsheet that is 

used in a tool for determining the capacity of wireless communication systems like system 
100. As was illustrated, this capacity analysis can also be done on a sector by sector basis. 
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The results of the capacity analysis can then be used to dimension the system to ensure 
adequate capacity is available for all subscribers. 

[047] While embodiments and implementations of the invention have been shown 

and described, it should be apparent that many more embodiments and implementations 
5 are within the scope of the invention. Accordingly, the invention is not to be restricted, 
except in light of the claims and their equivalents. 



- 18 - 



WO 02/28118 



PCT/EPO 1/11203 



18 



Bearer Service 
(Application mode) 


Percent 
subscribe 
ng to 
bearer 
service 


Percent of 
B using 
Applicant 
n Mode 


Sessions 
(Calls) 
per day 


Session 
(Call) 
Duration 


Usage 
Scaling 
Factor 


Busy Hour 
Factor 


Percent of Total 
subscribers using call 
type (F*C*B) j 


Average 
BHCA/SA per 
subscriber 
(H*D*G) 
AVbRAU-q 


A 


B 


C 


D 


E 


F 


Q 


H 


I 


CS/ PS ( Amplication 
mode) 




\7V 








% 


% 




PS Dabi AVeh Ann w/ 1 

images ON) 


80% 


20% 


3 


250 


JU/9 




fl r VUU /o 


0.048 


DC Tkati Al/ok Ann ■■>/ 

rft Data I^WCO App W/ 

images OFF) 


80% 


10% 


3 


250 


50% 


20% 


4,000% 


0,024 


PS Data (WEB App 
mini browser) 


80% 


70% 


3 


250 


50% 


20% 


28.000% 


0.168 


PS Data (Email laptop 
Fetch with attachment) 


80% 


30% 


5 


60 


50% 


20% 


12.000% 


0.12 


PS Data (Email laptop 
Fetch w/o attachment) 


80% 


30% 


5 


60 


50% 


20% 


12.000% 


0.12 


PS Data (Email laptop, 
Send with attachment) 


80% 


30% 


1.5 


60 


50% 


20% 


12.000% 


0.036 


PS Data (Email laptop. 
Send (without attachment) 


80% 


30% 


1.5 


6 


50% 


20% 


12.000% 


0.036 


PS Data (Email 
minibrowser,Fetch (with 


80% 


70% 


5 


60 


50% 


20% 


28.000% 


0.28 


PS Data (Email 
mJiubrowser,Fetch (w/o 
attachment)) 


80% 


70% 


5 


60 


50% 


20% 


28.000% 


0.28 


PS Data (Email 
minibrowser, Send (with 
attachment)) 


80% 


70% 


2 


5 


50% 


20% 


28.000% 


0.H2 


PS Data (Email 
mimbrowscn Send (w/o 
attachment)) 


80% 


70% 


1 


1 


50% 


20% 


28,000% 


0.056 


£*3 Data {Point of Sale) 


80% 


4% 


120 


IQ 


50% 


20% 


1.600% 


0,384 


PS Data (Push (type t)) 


80% 


5% 


W i 


5 


50% 


20% 


2.000% 


0.04 


PS Data (Push (type 2)) 


80% 


5% 


30 


1 


50% 1 


20% 




0.12 


r s Jjaia (rusn (type a)) 


eu/o 


5 /a 


2 ' 


120 


50% 


20% 


2.000% 


0.008 


PS Data (Localization 
(Pull)) 


80% 


1% 


1440 


1 


50% 


20% 


0.400% 


1.152 


PS Data (Telemetry 
(Pull)) 


80% 


i% 


24 


1 


50% 


20% ! 


0.400% 


0.0192 


FS Daw (Other son 
realtime (Pull)) 


80% 


3% 


1 


600 


50% 


20% 


1.200% 


0,0024 


"DC Tloia /l>a^V»f 

Video(Miiltimedia)) 


80% 


1% 


3,75 


300 


50% 


20% 


0.320% 


0.0024 


PS Data (VoIP (Voice)) 


80% 


4% 


4 


80.625 


5Q% 


20% 


1.600% 


0.0128 


PS Data (Other Tealtime 
(Multimedia)) 


80% 


4% 


1 


300 


50% 


20% 


1.600% 


0.0032 


CS Data (Long Multi- 
Media) 


0% 


0% 


1 


1800 


0% 


20% 


0.000% 


0 


CS Data (Short Multi- 


25% 


6% 


5 


300 


100% 


20% 


1.500% 


0.015 



- 19 - 



WO 02/28118 



PCT/EPO 1/1 1203 



19 



Media) 


















CS Data (Other Data Calls 
(Muuiiimcuia)) 


25% 


3% 


5 


300 


100% 


20% 


0.750% 


0.0075 


CS Voice (9.6 K) 


100% 


100% 


4.5 


90 


100% 


20% 


J 00.000% 


0.9 


CS Voice (14.4 K) 4 


100% 


0% 


4.5 


90 


100% 


20% 


0.000% 


0 



Table 1 



Bearer Service 
(Application mode) 


Number 
of 

packet 
calls per 

session 


Number of 
datagrams within 
a request 


Average Sfcze Of 
tfie Datagrams 


Average Busy 
Hour Traffic per 
Sub 


Peak Data Rate 
(Avg mease of CS 
Voice) 


Scheduler efficiency factor 


FWD 


REV 


FWD 


REV 


FWD 


REV 


FWD 


REV 


FWD 


REV 


A 


J 


K 


L 


M 


N 


O 


P 


Q 


R 


S 


T 


CS/ PS (Application 
mode) 




Bytes 


Bytes 


Bytes 


Bytes 


kbytes/ 
BH/'user 


kbytes/ 
BHAiser 


kbps 


kbps 






PS Data (Web App w/ 
images ON) 


10 


60 


30 


650 


65 


18.72 


.936 


38.4 


38.4 


0.728088646 


0.66550S021 


PS Data (Web App w/ 
image* OFF) 


10 


30 


15 


650 


65 


4.92 


0.474 


38.4 


38.4 


0.695149896 


0.663858083 


PS Data (WEB App 
xrunibrowser) 


10 


6 


3 


150 


65 


3.192 


2.0076 


38.4 


38.4 


0.663731396 


0.662540533 


PS Data (Email laptop 
Fetch with attachment) 


1 


630 


315 


325 


65 


24.69 


2.577 


76.8 


38.4 


0.734097504 


0.676498681 


PS Data (Email laptop 
Fetch w/o attachment) 


1 


15 


S 


325 


65 


0.705 


0.1824 


38.4 


3B.4 


0.665519097 


0.662453964 


PS Data (Email laptop. 
Send with attachment) 


I 


315 


630 


65 


325 


0,773! 


7,407 


38.4 


76.8 


0.676498681 


0.734097504 


PS Data (Email laptop. 
Send (without attachment) 


1 


a 


15 


65 


32S 


0.05472 


0.2115 


38.4 


3B.4 


0.666539635 


0.697190372 


PS Data (Email 
minibrowser.Fetch (with 
attachment)) 


i 


:35 


70 


i50 


65 


5.95 


i.554 


38.4 


38.4 


0.676340321 


0.665290356 


PS Data (Email 

!*inibrc?v/ser,Fetch (w/o 
attachment)) 


1 


4 


2 


150 


65 


0.448 


0.3164 


38.4 


38.4 


0.662510269 


0.662179474 


PS Data (Email 
minibrowser, Send (wiih 
attachment)) 


t 


70 


135 


65 i 


150 


0.6216 


2.38 


38.4 


38,4 


0.701484271 


0.834083854 


PS Data (Email 
minibrowser, Send (w/o 
attachment)) 


1 


2 


4 


65 


150 


0.06328 


0.0696 


38.4 


38.4 


0.672768438 


0.692616146 


PS Data (Point of Sale) 


1 


5 


5 


230 


230 


0.8256 


0.8256 


38.4 


38.4 


0.667384219 


0.667384219 


PS Data (Push (type 1)) 


1 


20 


20 


500 


65 


0.44 


0.092 


38.4 


38.4 


0.747514063 


0.674O35313 


PS Data (Push (type 2)) 


1 


1 


t 


100 


65 


0.132 


0.1278 


38.4 


38.4 


0.671501563 


0.670023542 


PS Data (Push (type 3)) 


1 


400 


400 


500 


65 


1.608 


0.216 


38.4 


38.4 


0.73242S933 


0.671193641 


PS Data (Localization 
(Pull)) 


1 


0 


1 


0 


30 


1.152 


1.18656 


38.4 


38.4 


0.667278646 


0.668545521 


PS Data (Telemetry 
(Pull)) 


1 


0 


1 


0 


100 


0.0192 


0.02112 


38.4 


38.4 


0,667278646 


0.671501563 


FS Data (Other non 
realtime (Pull)) 


1 


3500 


17 


550 


60 




0.00494 

8 


38.4 


38.4 


0.7S»74S»4041 


0.662O80S87 



- 20 - 



WO 02/28118 



PCT/EP01/11203 



20 



PS Data (Packet 
Vidco(Multimedia)) 




60000 


60000 


60 


60 


8.6424 


8,6424 


153.6 


153.6 


0.7S8691S99 


0.783691899 


PS Data {VoIP (Voice)) 


1 




1066 


1066 


6D 


60 


0,83143 
8 


o.m4« 
s 


38.4 


38.4 


0,695565968 


0,695565968 


PS Data (Other re a f tunc 
(Multimedia)) 




SOOOO 


17 


60 


60 


153632 


0.00646 
4 


153,6 


153.6 


0.830921066 


0.662040294 


CS Data (Long M til It- 
Media) 












0.00 


0,00 










CSData (Short Multi- 
Media) 












S.]0 


8.10 


14.40 


14.40 


0.58 


. 0.58 


CS Data (Other Data Calls 
(Multimedia)) 












4.05 


4.05 


14.40 


14.40 


0.58 


0.58 


CS Voice (9.6 K) 












43.74 


43.74 


9.60 


9.60 


0.58 


0,58 


CS Voice (14,4 K) 












0.00 


0,00 


34.40 


14.40 


0.58 


0.58 



Table 1 (continued) 



- 21 - 



WO 02/28118 



PCT/EPOi/11203 



21 



Bearer Service (Application mode) Air Interface Framing 

Overhead Correction [eg. 
for fwd link 1- 
(24+50/(05*1000))] : 


MAC Layer Framing 
Overhead Correction 
Factor (UMAC 
Overhead) 


RLP Retransmission 
Overhead (1 - 
(FER*19.2/Q)] 


Noimalized Traffic per subscriber 
in Busy Hour [e.g. for fwd link 
05/(S5*U5*W5+Y5)J RAW 
DATA BITS 




FWD 


REV 


FWD 


REV 


FWD 


REV 


FWD 


REV 


A 


U 


V 


W 


X 


Y 


Z 


AA 


AB 


CS/ PS (Application mode) 














kbytes/BH/user 


kbyte s/BH/user 


PS Data (Web App w/ images ON) 


0.96875 


0.9687S 


0.875 


0.875 


0.975 


0.975 


31.9074859 


2.57446821 


PS Data (Web App w/ images OFF) 


0.96 B 75 


0*96875 


0.875 


0.875 


0.975 


0.975 


S,5oj f JcilXO 




PS Data (WEB App mmibrowser) 


0.96875 


0.96875 


0.875 


0.875 i 


0.975 


0.975 


5.818970256 


3.66640427 


PS Date (Email laptop Fetch with 
attachment) 


0.984375 


0.96875 


0.875 


0,875 


0.9875 


0.975 


39.54227112 


4.60917376 


PS Data (email Japtop retcn w/o 


0.9Oo75 




0.875 


0.875 


0.975 


0.975 


1.2BI f>£.ol 


u.jjj i j J fa 


PS Data (Email laptop, Send with 
attachment) 


0.96875 


0.984375 


0.875 


0.875 


0.975 


0.9875 


1,382752127 


11.8626813 


PS Data (Email laptop, Send (without 
attachment) 


0.96875 


0.96875 


0.875 


0.875 


0.975 


0.975 


0.099333497 


0.36705761 


PS Data (Email minibrowser f Fetch 
(with attachment)) 


0.96875 


0.96875 


0.875 


0.875 


0.975 


0.975 


10.6445499 


2.82628141 


PS Data (Email minibrowser^Feich 
(w/o attachment)) 


0.96875 


0.96875 


0.875 


0,875 


0.975 


0.975 


0.818202902 


0.57814447 


PS Data (Email minibiowser, Send 
(with attachment)) 


0.96875 


0.96875 


0,875 


0.875 


0.975 


0.975 


1.072182425 


3.45257291 


PS Data (Email minibiowser. Send 
(w/o attachment)) 


0,96675 


0.96875 


0.875 


0.875 


0.975 


0.975 


0.113808966 


u. 15652763 


PS Data (Point of Sale) 


0.96875 


0,96875 


0,875 


0.S75 


0.975 


0.975 


1.496813275 


1.4963:928 


PS Data (Push (type 1)) 


0,96375 


0.96875 


0.875 


0.875 


0.975 


0.975 


0,712211407 


0.16515084 


PS Date (Push (type 2)) 


0,96875 


0,96875 


0.875 


0.875 


0,975 


0.975 


0.237849651 


0.23078969 


PS Date (Push (type 3)) 


0.96875 


0.96875 


0.875 


0.B75 


0*975 


0.975 


2.656427375 




PS Date (Localization (Pull)) 


0.96875 


0,96875 


0,875 


0.875 


0.975 


0.975 


2.088915479 


2.14750575 


f!S Date (Telemetry (Pull)) 


0.96875 


0-96875 


0.875 


0.875 


0.975 


0.975 


0.034815258 


0.03805594 


PS Data (Other non realtime (Pull)) 


0,96875 


0.96875 


0.875 


0.875 


0,975 


0.97S 


7.013191435 


O.O0S85987 


PS Data (Packet Videopviultimedia)) 


0,9921875 


0.9921875 


0.875 


0.875 


0.99375 


0.99375 


12,701296 


12,701296 


PS Date (VoIP (Voice)) 


0.96875 


0.96875 


0,875 


0.875 


0.975 


0.975 


U446416198 


1.4464162 


PS Data (Other realtime 
(Multimedia)) 


0,9921875 


0.9921875 


0.875 


0.875 


0.99375 


0.99375 


23.43102628 


0.OU31717 


CS Date (Long Multi-Media) 


















CS Date (Short Multi-Media) 


0.9166666 
7 


0.91666667 


0.S75 


0,875 


0.9333333 
3 


0.9333333 
3 


18.65523639 


18.6552364 


CS Data (Other Date Calls 
(Multimedia)) 


0.9166666 
7 


0.91666667 


0.B75 


0.875 


0.9333333 
3 


0,9333333 
3 


9327618195 


9.32761819 


CS Voice (9.6* JC) 


1 


1 


1 


1 


1 


1 


75.41 


75.41 


CS Voice (14.4 K) 


1 


1 


1 


1 


1 


1 


0.00 


0.00 



Table 1 (continued) 



- 22 - 



WO 02/28118 



PCT/EP01/11203 



22 

Claims 

1. A method of dimensioning a wireless communication 
system configured to support a plurality of applications, comprising: 

for each application, estimating a percentage of subscribers of the 
5 wireless communication system that will use the application; 

for each application, determining a subscriber profile for the 
application based at least in part on the estimated percentage of 
subscribers that will use the application; and 

for each application, determining a busy hour traffic per subscriber 
10 ratio for the application based at least in part on the subscriber profile for 

the application. 

2. The method of claim 1, further comprising: 

for the wireless communication system, determining a total busy 
hour traffic per subscriber ratio from the busy hour traffic per subscriber 
1 5 ratios determined for each application; 

for the wireless communication system, estimating a total traffic 
capacity; and 

for the wireless communication system, determining a number of 
subscribers the wireless communication system will support by dividing 
20 the estimated total traffic capacity by the determined total busy hour 

traffic per subscriber ratio, 

3. The method of claim 2, wherein the total busy hour traffic 
per subscriber ratio is determined for both a forward link and a reverse 
link in the wireless communication system. 

25 4. The method of claim 2, further comprising: 

for each application, estimating a scheduler efficiency factor; and 
for each application, normalizing the busy hour traffic per 

subscriber ratio based at least in part on the estimated scheduler efficiency 

factor to determine a required Raw Data Bits. 
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5* The method of claim 4, wherein determining the total busy 
hour traffic per subscriber ratio for the wireless communication system 
comprises summing the required Raw Data Bits for each application, 

6. The method of claim 5, wherein normalization of the busy 
hour traffic per subscriber ratios for each application is further based on at 
least one of the following: air interface framing overhead, MAC layer 
framing overhead; and RLP retransmission overhead* 

7. The method of claim 5, wherein the busy hour traffic per 
subscriber ratios, required Raw Data Bits, and the total busy hour traffic 
per subscriber ratio are each measured in kilobytes per hour per 
subscriber, and wherein the total traffic capacity is measured in kilobytes 
per hour. 

8. The method of claim 1, wherein estimating the percentage 
of subscribers of the wireless communication system that will use a given 
application is estimated by: 

estimating or measuring a first percentage, the first percentage 
being the percentage of subscribers of the wireless communication system 
that subscribe to a bearer service that supports the application; 

estimating or measuring a second percentage, the second 
percentage being the percentage of subscribers that subscribe to the 
respective bearer service and that will actually use the application; 

estimating a usage scaling factor; and 

multiplying the first percentage, the second percentage, and the 
usage scaling factor. 

9. The method of claim 8, wherein determining a subscriber 
profile for each application comprises: 

estimating or measuring a number of application sessions that an 
average subscriber included in the second percentage will engage in per 
day; 



WO 02/28118 PCT7EP03/11203 

24 

estimating or measuring an average duration of each application 
session; 

determining a busy hour factor based on the measured or 
estimated number of application sessions and the measured or estimated 
5 average duration of each application session; and 

multiplying the determined busy hour factor by the second 
percentage to determine the subscriber profile for the application. 

10* The method of claim 9, wherein determining a subscriber 
profile for a given application farther comprises: 
10 averaging the determined subscriber profile over the total number 

of subscribers of the wireless communication system to derive an average 
subscriber profile for the application. 

11. The method of claim 9, wherein determining the busy hour 
traffic per subscriber ratio for a given application comprises: 

15 estimating or measuring a number of bytes per application session; 

and 

multiplying the estimated or measured number of bytes per 
application session by the determined subscriber profile* 

12. The method of claim 1, wherein the plurality of 
20 applications includes both circuit switched and packet data applications. 

13. The tool of claim 12, wherein all packet data applications 
are considered interactive classes of traffic and all circuit switched 
applications are considered conversational classes of traffic* 

14. The method of claim 1, wherein the capacity of the 
25 wireless communication system is determined on a per sector basis. 

15. A computer readable medium having stored thereon one or 
more sequences of instructions for causing one or more processors to 
perform steps for dimensioning a wireless communication system 
configured to support a plurality of applications, the steps comprising: 
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for each application, estimating a percentage of subscribers of the 
wireless communication system that will use the application; 

for each application, determining a subscriber profile for the 
application based at least in part on the estimated percentage of 
5 subscribers that will use the application; and 

for each application, determining a busy hour traffic per subscriber 
ratio for the application based at least in part on the subscriber profile for 
the application. 

16, The computer readable medium of claim 15, wherein the 
1 0 steps further comprise: 

for the wireless communication system, determining a total busy 
hour traffic per subscriber ratio from the busy hour traffic per subscriber 
ratios determined for each application; 

for the wireless communication system, estimating a total traffic 
15 capacity; and 

for the wireless communication system, determining a number of 
subscribers the wireless communication system will support by dividing 
the estimated total traffic capacity by the determined total busy hour 
traffic per subscriber ratio. 

20 17. The computer readable medium of claim 16, wherein the 

steps iiUuioi COmpriSC! 

for each application, estimating a scheduler efficiency factor; and 
for each application, normalizing the busy hour traffic per 
subscriber ratio based at least in part on the estimated scheduler efficiency 
25 factor to determine a required Raw Data Bits. 

18, The computer readable medium of claim 17, wherein 
determining the total busy hour traffic per subscriber ratio for the wireless 
communication system comprises summing the required Raw Data Bits 
for each application. 
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19. A system configured to dimension a wireless 
communication system configured to support a plurality of applications, 
the system comprising: 

a processor; 

a data storage area; and 

an execution area configured to: 

for each application, estimate a percentage of subscribers 
of the wireless communication system that will use the application; 

for each application, determine a subscriber profile for the 
application based at least in part on the estimated percentage of 
subscribers that will use the application; and 

for each application, determine a busy hour traffic per 
subscriber ratio for the application based at least in part on the subscriber 
profile for the application. 

20. The system of claim 19, wherein the execution area is 
further configured to: 

for the wireless communication system, determine a total busy 
hour traffic per subscriber ratio from the busy hour traffic per subscriber 
ratios determined for each application; 

for the wireless communication system, estimate a total traffic 
capacity; and 

for the wireless communication system, determine a number of 
subscribers the wireless communication system will support by dividing 
the estimated total traffic capacity by the determined total busy hour 
traffic per subscriber ratio. 

21. The system of claim 20, wherein the execution area is 
further configured to: 

for each application, estimate a scheduler efficiency factor; and 
for each application, normalize the busy hour traffic per subscriber 

ratio based at least in part on the estimated scheduler efficiency factor to 

determine a required Raw Data Bits* 
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22. The method of claim 21, wherein determining the total 
busy hour traffic per subscriber ratio for the wireless communication 
system comprises summing the required Raw Data Bits for each 
application. 
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